The activities of enterprises are highly intertwined with computers. For many enterprises, computer system unavailability can be disabling. The ability to maintain availability is therefore an important capability of computer systems.
Computers systems used by enterprises store and retrieve large amounts of data. Typically, the computer systems rely on database systems to perform this function. Therefore, a database system's capability to maintain availability is very important.
Replication is one technique used to maintain the availability of database systems. Replication is the process of replicating data from a “primary” database system onto another database system, herein referred to as a standby. As changes are made to user data on the primary database system, the changes are replicated on the standby. If the primary database system becomes unavailable, the standby can be made primary.
One approach to replication is the physical standby approach. Under this approach, the changes made to data blocks on the primary database are made to replicas of those data blocks on a physical standby. Because the primary database system is replicated at the lowest atomic level of storage space on the standby, the physical standby is a physical replica of the primary database system.
Another approach to replicating data is the logical standby approach. Under the logical standby approach, database commands that modify data on the primary system are re-executed on a logical standby. While executing the same database commands guarantees that changes are replicated at the record level, the changes are not replicated at the data block level. This change in replication strategy allows a logical standby to be available for reporting applications while replication is being performed—an advantage over a physical standby.
Typically, changes to database systems are made using transaction processing. A transaction is a set of operations that change data. In database systems, the operations are specified by one or more database commands. Committing a transaction refers to making the changes for a transaction permanent.
Under transaction processing, all the changes for a transaction are made atomically. When a transaction is committed, either all changes are committed, or the transaction is rolled back. Because the changes are not permanent until a transaction is committed, the changes for a transaction are not replicated on a logical standby until the transaction is committed on the primary database. After a transaction is committed on the primary database system, the transactions are re-executed and committed on the logical standby.
To replicate data on a logical standby more quickly and efficiently, transactions are executed in parallel. Transactions may be executed in parallel by multiple processes, each process executing one of the transactions. The efficiency of the replication process may be improved by increasing the number of transactions executed in parallel.
Under conventional approaches, certain conditions can force transactions to be executed serially at a logical standby. For example, if a pair of transactions includes operations that modify the same records, then the transactions are not executed in parallel. Instead, the transactions in the pair are executed in serial, with the first transaction to be committed on the primary being executed first. The transactions are serialized under these conditions to ensure that operations to the same records are committed in the same order on the replicated system as they are on the primary database system.
Based on the foregoing, it is clearly desirable to develop an approach that allows operations in two or more transactions to be executed in parallel when the transactions modify the same records.